This change looks good but I am a bit worried that this will cause an additional build on the CI.

This change looks good but I am a bit worried that this will cause an additional build on the CI.

Yes and it will... Perhaps an idea to move it to postInstall?

@piotr-cz could you rebase your PR with master?

Yes and it will... Perhaps an idea to move it to postInstall?

I guess that will just move the problem, no? Perhaps we should leave this change out, it's not that much of an effort to run the build manually as a contributor.

I guess that will just move the problem, no? Perhaps we should leave this change out, it's not that much of an effort to run the build manually as a contributor.

That's right, but then it should be stated in readme

@jonkoops

This change looks good but I am a bit worried that this will cause an additional build on the CI.

Are there any CIs configured besides Travis, which has been removed recently (7dda02a)?

@piotr-cz Yes, we have Github actions configured for this: https://github.com/Amsterdam/matomo-tracker/actions

Ah I see.
Then I'd suggest to remove the build action from CI if this PR is merged or in new commit to this PR.

I mean there is inconsistency: At this moment test script doesn't run build - but GitHub action does.

When thinking more about it, I'd suggest to move tests from GIT hooks in package.json to GitHub Actions triggered on Pull Requests as one of the PR checks.

This way contributors won't be forced to install, build and test package when submitting changes (to ie. readme) but will have an option to do so before submitting pull requests.

And you'll still be covered by CI tests.

Of course this means that you as maintainers would have to push commits trough Pull Requests and not directly to master or remember to run tests manually on local environment.

When thinking more about it, I'd suggest to move tests from GIT hooks in package.json to GitHub Actions triggered on Pull Requests as one of the PR checks.

Yeah, that's why I added the CI for the users that don't run these things locally. I think the hooks can still be beneficial, if people want to prevent running them they can use the --no-verify flag when committing, pushing, etc.

Considering these things I am going to close this PR as I think we are pretty much covered and I don't want to risk running our builds multiple times.

@jonkoops
To be honest I haven't seen a project with tests triggered by GIT hooks for long time, usually just on CI.

Thanks for spending time on this PR anyway,